In a multi-core platform, such as an advanced cable gateway, one of the multiple processing cores, the “primary core,” typically will have wide area network (WAN) connectivity and will implement a Dynamic Host Configuration Protocol (DHCP) client to obtain a globally routable Internet Protocol (IP) address from a remote DHCP server. The DHCP server will respond to an IP lease request from the DHCP client with a DHCP offer message that will typically contain a list of IP addresses of Domain Name System (DNS) servers that the client can use for resolving domain names (e.g., “www.technicolor.com” is resolved as IP address 157.254.235.97).
The other processing cores (“secondary cores”) in such a multi-core platform may host their own operating systems with network applications (e.g., HTTP browser, stock ticker, etc.) that also require DNS resolution services. Additionally, any number of client devices such as computers, game systems, or the like, may be attached to and dependent on one or more secondary processing cores for access to the internet. Typically, these secondary cores do not have direct WAN connectivity but instead may use Internet Engineering Task Force (IETF) Class A, B, or C private networks (either physical or virtual) to communicate with the primary core and with each other. For simplicity, secondary core network interfaces typically use fixed Class A, B, or C private network addresses (e.g., 192.168.0.xxx) and do not implement local DHCP clients to obtain private IP addresses from the primary core. A limitation of using fixed private network addresses, however, is that the secondary cores cannot directly provide DNS resolver services to the network applications running on those cores and/or client devices attached thereto.
One approach to this problem is for the primary core to host a private DHCP server to serve private IP addresses to each secondary core. The private DHCP server could pass to the secondary cores, in private DHCP offers, the DNS server IP list acquired from the WAN-side DHCP server. This approach also requires each secondary core to implement a DHCP client. More limiting however, the primary core DHCP server must be able to support multiple DHCP scopes in order to allocate a known fixed IP address to each secondary core, based on, for example, the network interface identifiers—such as the Media Access Control (MAC) addresses—of the secondary cores. A drawback of this approach is that multiple-scope DHCP server capability adds significant product complexity, and as mentioned, it also requires each secondary core to implement a DHCP client, adding further complexity to the multi-core platform.
A need exists, therefore, for an arrangement without the aforementioned shortcomings that allows a multi-core platform to provide DNS resolution services to network applications running on secondary cores, and/or clients of secondary cores, with no direct WAN connectivity.